fix(deploy): deploys were silent no-ops (hosts: vds never matched)#53
Merged
Conversation
The playbook declared 'hosts: vds', but since tmfeed/inventory.ini was removed the CI passes the host inline (-i "<host>,"), which places it in the implicit 'all' group — never 'vds'. Every deploy since then printed 'Could not match supplied host pattern, ignoring: vds / skipping: no hosts matched' and exited 0, so releases 5.0.0/5.1.0 and the log-rotation change never actually reached the server (stuck on 4.0.0rc7). - deploy.playbook.yml: hosts: vds -> hosts: all. - deploy.yml: fail fast if DEPLOY_HOST/DEPLOY_USER are empty, so a misconfigured target can never again pass as a silent no-op deploy.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Что не так
Бот на сервере запущен, но не доставляет посты: тянет ленты (habr/opennet, HTTP 200), но каждый тик падает —
Файловый кэш (~13.5 MB) побился, когда диск забился под 100 % (запись оборвалась). Плюс сервер до сих пор на
4.0.0rc7со старым files-cache setup, хотя выходили релизы 5.0.0 / 5.1.0.Первопричина: деплой давно молча ничего не делает. После удаления
tmfeed/inventory.iniCI передаёт хост инлайном (-i "88.218.64.96,") → он попадает в неявную группуall, а плейбук объявленhosts: vds:Playbook пропускается, job рапортует success. Так «деплоились» 5.0.0, 5.1.0 и предыдущий PR #52 — на сервер ничего не попадало.
Фикс
tmfeed/deploy.playbook.yml:hosts: vds→hosts: all(инлайн-хост из CI всегда попадает вall)..github/workflows/deploy.yml: падать, еслиDEPLOY_HOST/DEPLOY_USERпусты — чтобы деплой больше никогда не «проходил» вхолостую.Что произойдёт при мерже
Деплой реально отработает: развернёт
:latest(5.1.0) с redis-кэшем +--force-recreate, применит ротацию логов из #52. Новый redis-кэш пуст → первый прогон заполнит кэш без отправки (штатная защита от спама), затем возобновит доставку постов. Это чинит и падающие тики, и версию, и логи разом.Проверка после деплоя
docker compose psв/home/worker/feedforbot→feedforbot+feedforbot-redis, оба healthy.docker logs feedforbot— тики безscheduler_tick_error.docker inspect feedforbot --format '{{.HostConfig.LogConfig.Config}}'→max-size:10m.@tmfeed.